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THE  SATMODEL  USEP'S  GUIDE 


CHAPTER  1:  INTRODUCTION 


During  the  past  several  years  a set  of  proqrams  has 
been  developed  at  the  University  of  North  Carolina  to  model 
and  optimize  the  performance  of  satellite  qraphics  systems^ 
of  the  form  shown  in  Fiqure  1.  Details  of  the  modelling  and 
optimization  techniques  have  been  reported  previously 
TGraphics  System  Modelinq,  First  Annual  Peport,  UNC,  June 
1974.  Graphics  Model  Verification,  Second  Annual  Report, 

c 

UNC,  November  1975  ].  The  programs,  oriqinally  executed  as 
batch  lobs  on  an  IBM  360  or  i70  with  OS/360,  have  now  been 
converted,  extended,  and  augmented  to  execute  interactively 
on  a Honeywell  645  or  6045  with  the  MULTICS  operating 
system.  This  guide  describes  the  basic  concepts  involved  in 
usinq  the  interactive  proqrams,  which  are  herein  referred  to 
as  SATMODFL.  A companion  document,  I£e  hs££E§S££ 

flajiual,  gives  details  of  the  system's  use. 


The  considerations  in  the  design  of  satellite  qraphics 
systems  have  beer.  extensively  discussed  in  the  two 
previously  cited  reports,  and  elsewhere  fJ.D.  Foley, 

"Satellite  Graphics  Systems",  £2*E!li££*  August  1976. 

, "Software  for  Satellite  Graphics  Systems", 

ECOCgeiiDls  A£M  J2IJ  C2IllSI§DC§,  76-80.  , 

"An  Approach  to  the  Optimum  Design  of  Computer  Graphics 


2 


Systems'* , C£CM  14  (6),  380-390,  June  197  1.  , "The 

Desiqn  of  Satellite  Graphics  Systems",  in  Data  S£j:uctu£§s  in 
Pattern  P^coqni  tign  and  Computer  i»r  aghi.cs,  A.  Klinqer,  ed. 
Academic  Press,  1976.  A.  van  Dan,  et . al.,  "Intelligent 
satellites  for  interactive  graphics",  proceedings  of  th< 
IIES  62  (4),  April  1^74.  "Operating  system  desiqn 

considerations  for  microprogrammed  minicomputer  satellite 
systems"".  Proceeding  1973  NFC.  1 The  two  basic  issues  are 
choosinq  capabilities  (speed,  size)  of  the  subsystems  shown 
in  Fiqure  1.1,  and  selecting  the  appropriate  "division  of 
labor"  for  the  applications  program.  The  subsystem 
capabilities  should  ne  in  balance  one  with  another,  so  that 
no  cne  subsystem  acts  as  a bottleneck  to  system  operations. 
The  divisions  of  labor  must  recognize  that  there  are  two 
computers  and  storage  hierarchies  in  the  satellite  system 
and  that  programs  and  files  must  be  assigned  to  them  in  an 
effective  way.  The  basic  optimization  process  aims  to 
design  a satellite  system  with  minimum  response  time  and 
cost  not  exceeding  a specified  bound. 
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Definition  of  F esponse  Time 

Response  lime  is  measure!  for  a typical,  or  average 
interaction.  An  interaction  is  the  activity  of  the  system 
which  occ  ur  -rh  ar  the  user  invokes  some  command.  Thus  a 
typical  interaction  starts  wh°n  the  ser  hits  the  carriage 
return  on  the  keyboard,  lightpens  an  option  on  the  menu., 
etc.  At  this  point,  the  system  must  process  the  command,  jo 
program  control  will  pass  to  some  of  the  many  subroutines  or 
sections  or  the  program,  eventually  returning  information 
the  user.  The  system  than  waits  for  the  user  to  initiate 
another  interaction.  Tha  response  time  is  the  time  between 
the  user's  last  action  in  initiating  the  command  and  .ho 
response  appearing  on  the  li. splay. 

Definitions  of  Cost 

The  cost  of  a satellite  graphics  system  is  defined  h-.re 
co  be  the  sum  of  the  costs  of  five  of  the  subsystems  shown 
in  Figure  1.  They  are: 

1.  Display  Processing  Unit  (DPU) 

(including  hardware-software  tradeoff  options), 

2.  Satellite  Computer, 

1 . Satellite  computer  Main  Memory, 

4.  Satellite  Computer  bulk  Memory, 

■5.  Communications  Link. 

The  subsystem  costs  (and  hence  the  system  cost)  can  be 
specified  in  arbitrary  units,  and  with  various  meanings 
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includinq,  but  not  limited  to: 


purchase  price 
purchase  price 
monthly  rental 
monthly  rental 
purchase  price 


in  Dollars, 
in  Pounds, 
price  , 

plus  monthly  maintenance  price, 
plus  five  year's  maintenance. 


The  only  requirement  is  that  all  costs  be  consistently  qiven 
in  the  same  units  and  with  the  same  meaninq. 

The  basic  optimization  process  takes  as  its  inputs: 

1.  A description  of  the  cost  and  performance  of  a 
number  of  choices  for  each  of  the  five  subsystems. 

2.  A description  of  the  intaractive  application  proqram 
to  be  used  with  the  satellite. 

3.  An  upper  bound  on  the  cost  of  the  system. 


The  results  of  the  optimization  process  are: 

1.  The  optimum  choice  of  equipment  for  each  of  the  five 
subsystems  which,  when  used  with  the  division  of 
labor  from  2 below,  minimizes  response  tine.  Total 
cost  of  the  subsystem  is  less  than  the  upper  bound. 

2.  The  optimum  division  of  labor  for  the  above  optimum 
selection  of  subsystems. 

3.  Detailed  information  on  the  performance  and 
utilization  of  each  of  the  five  selected  subsystems. 


. 7*' 
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There  are 


ho  we  ve  r 


yet  other  dimensions  to 
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optimization  process.  We  call  these  h ardwar e-soft uare 
tradeoffs,  and  selective  specifications.  They  are  descriled 
in  the  followim  two  sections. 
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1.1  Hardware-Software  Tradeoffs 

A number  of  graphics  functions  can  be  implemented  tfith 
either  special-purpose  display-processor  ha£dwa£§,  or  with 
satellite  processor  software.  Examples  are  dynamic  or 
static  transformations  and  clipping,  subpicturing,  and  text 
display.  The  special  hardware  is  usually  more  expensive  and 
faster  in  operation  than  the  software. 

The  tradeoff  in  designing  a minimum  response  time 
system  is  between  the  cost  of  the  DPU  hardware  and  the  cost 
of  one  or  more  of  the  other  subsystems.  The  optimization 
process  automatically  determines  which  of  the  alternatives 
will  yield  the  fastest  response  time.  This  can  be  done  for 
one  or  several  such  tradeoffs. 


1.2  Selective-  Speci f icat ion 


a 


Choosinq  the  subsystems  for  use  in  a satellite  system 
can  involve  issuers  oth»t  than  cost  and  response  time.  The 
prime  example  ot  such  issues  is  in  the  area  of  display 
quality,  where  criteria  such  as  resolution,  linearity,  spot 
size,  intensity  levels,  and  flicker  can  all  be  very 
important . 

He  have  accordingly  provided  a qeneral  curl  .nq 

(selection)  mechanism  to  ensure  that  only  those  subsyst  ms 
meetinq  specified  minimum  criteria  are  considered  for 
selection  by  the  basic  optimization  process.  There  is  also 
a special- purpose  mechanism  to  handle  the  important  but 
unique  and  complex  matter  of  flicker-free  display 

ca  oa  hi li t y . 

The  information  needed  to  analyze  hardware-software 
tradeoff  and  to  effect  selective  specifications  is  included 
in  the  inputs  to  the  optimizer. 
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1.3  SAT  MODE  L 

c 

v 

(Jsinq  the  SATMODEL  system  is  a multistep  process.  The 
Pile  Editor  subsystem  (P^D)  is  first  used  to  build  two 
files,  one  describinq  the  subsystem  choices,  and  best 
hardware,  the  other  describinq  the  application  proqram.  The 
optimization  subsystem  (OPT)  is  then  used  to  perform  an 
optimization.  Finally,  the  report  qeneratinq  subsystem 
(PEP)  is  used  to  select  that  portion  of  the  optimization's 
potentially  voluminous  output  which  is  to  be  printed  as  a 
report.  The  three  subsystems  all  operate  under  the  control 
of  the  SATHODEL  executive  (EXEC).  It  is  the  detailed  use  of 
EXEC  and  its  FED,  OPT,  and  33P  subsystems  which  is  discussed 
. in  the  companion  document. 


1.4  Pemarks 


In  the  following  section-;,  ./  .'ill  ort;n 

names:  program  module  names,  file  names,  subsystem  :• 

etc.  These  names,  when  entered  into  the  system,  may  b. 
to  80  characters  in  length.  However,  when  printed  out 
describe  the  results  of  the  optimization  process,  the 
may  be  truncated  to  40  characters. 

All  measures  of  size,  be  it  of  main  or  backing  r.  Jt- 
programs,  files,  or  messages,  ire  given  in  units  of 
while  measures  of  time  will  he  in  units  of  seconds, 
will  always  be  specified  in  bytes  per  second,  or  secc r 
byte . 

Various  abbreviations  used  are  those  of  the  com  , 

Its  S AT ’jQDFL  Pe f e^encg  !!inual«  referred  to  hereafter  a 


CHAPTER  2: 


HARDWARE  DESCRIPTION 


1 1 


2.  1 General 

The  basic  hardware  specif ications  are  provided  in  the 
hardware  descriptons  (HP)  file,  of  f SRH,  Section  5.2.2]. 
The  purpose  of  the  hardware  description  file  is  to  provide 
the  optimizer  with  data  concerninq  all  available  hardware 
components.  This  data,  when  combined  with  application  data, 
yields  the  parameters  by  which  performance  and  cost  can  be 


determined.  This  data  is  qleaned  from  manufacturers’ 
cataloques  and  similar  sources,  and  supplies  the  basic 
speed,  capacity,  and  cost  information  for  each  component 


available  from  some  vendor.  This  basic  information  chanqes 
slowly,  and  is  qenerally  indepandent  of  the  application 
proqram  which  the  SATNODKL  user  intends  to  optimize. 


The  basic  data  is  separated  into  five  qroups, 
representinq  data  links  (DL) , remote  fast  stores  (FPS), 
remote  bulk  stores  (FBS)  , remote  CPU’s  (CPU),  and  remote 
DPU’s  (DPU) . There  must  be  at  least  one  item  in  each  of 
these  qroups. 

Pach  hardware  item  in  one  of  these  qroups  is  identified 
by  a name  entry,  uniquely  listinquishinq  it  from  other  items 
in  the  same  qroup.  For  example,  no  two  data  links  may  have 
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1 2 

The  name,  consistin')  of  60  or  fewer  characters 
normally  identifies  a manufacturer  or  source,  and  a mode! 
name,  so  that  the  item  is  readily  recognized  when  th 
SATNODEL  output  lists,  by  name,  the  optimal  components,  eirl 
so  that  it  is  easily  recalled  for  data  modification. 

Each  hardware  item  is  also  supplied  with  a number  o 
attributes,  measurinq  its  cost  and  per  Lor mance.  I. 
particular,  every  item  has  a cost  attribute.  Units  of  cos- 
can  be  any  measure,  such  as  dollars  per  month  (rental), 
dollars  (purchase).  The  choice  of  unit,  however,  roust  t 
consistent  throuqhout  the  hardware  description  file  and 
application  file  that  is  used  with  it.  Performance  measure.-, 
are  different  for  different  qroups,  and  will  be  ta< 
explicitly  described  in  section  2.2. 


One  group  in  th°  hardware  description  file  describe., 
the  performance  attributes  of  the  host  computer  ( H C ) , but  i . 
not  provided  with  a cost  since  SAT’IODEI.  does  not  provide  fo 
optimizing  the  choice  among  alternative  host  machines.  Thi; 
group  of  performance  attributes  is  also  described  in  seel  it. 
2.2. 


The  hardware  file  also  provides  data  for  select  i< 
based  on  specific  characteristics,  supporting  the  "selecti 
specification"  capability  described  in  section  1.2.  Th« 
function  and  content  of  this  data  are  described  3n  sectio 
2 . U . if  a user  does  not  intend  to  make  use  of  selective 
specification  features,  the  data  fields  associated  with  thi 
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feature  nay  be  iqnored. 

Similarly,  there  are  data  fields  associated  with 
hardware-software  tradeoff  which  are  described  in  section 
2.3,  and  may  be  iqnored  by  a user  who  does  not  intend  to 
consider  optimizations  where  hardware-software  tradeoffs  are 
intended. 


14 


2.2  Basic  P'ir for mnce  Data 

The  basic  performance  data,  that  which  is  necessr.r v 
even  when  hard  ware- so  ft  ware  tradeoff  features  and  selective 
specification  features  are  not  used,  is  described  in  this 
section.  pach  qroup  has  distinctive  fields  tor  this  data. 

1.  Data  Link  (PL) 

2.  Remote  Fast  Store  (FFC) 

3.  Femote  Bulk  Store  (BBC) 

4.  Pemote  Computer  (CPH) 

5.  Display  Processor  (DPP) 

6.  Host  Computer  (HC) 

Data  Link  (LI.) 

For  each  data  link,  a sjjggd  and  ar  ovgrhsjd  must  be 
prov id  ad  . 

Speed  (DLS°)  represents  the  transmission  rate  of  which 
the  data  link  is  capable  in  bytes  per  second.  ft  speed 
specification  is  mandatory  for  each  data  link  entry. 

Overhead  (DLO)  represents  the  overhead  time  in  seconds 
associated  with  one  transmission  across  the  data  link. 

Remote  Fast  store  fPFS ) 

Por  each  r^mot®  fast  store  a sij£  must  be  provided. 


15 

Size  ( RFSI)  represents  the  number  of  bytes  in  the 
store. 


S9J“Ot£_BuJLk_StO££_J£BS) 

For  each  remote  bulk  store  a size,  a SQek-jatgpcy  tiig, 
and  a ifgnsffil  ting  must  be  provided. 

Si2S  (FBSI)  represents  the  number  of  bytes  available  in 
the  store. 

Seek»Latencv  ti«g  (SLT)  represents  the  averaqe  seek 
plus  latency  time  ("access  time")  associated  with  the  bulk 
store  facility,  in  seconds. 

Transfer  time  (TRT)  represents  the  transfer  time  per 
bvte  associated  with  the  bulk  store,  in  seconds  per  byte. 

For  each  remote  CPM  a §2§§3.  a Mii»aa  fast  si2I£  liSS* 
and  an  operating  system  size  must  be  provided. 

Sfiegd  (CSP)  represents  th»  number  of  hiqh-leveJ 
instructions  per  second  that  the  processor  is  capable  of 
executinq . 

fla*inyi  fast  §to£e  (MFS)  represents  the  larqest  amount 
of  remote  fast  store  which  the  remote  CPU  is  capable  of 
supporting,  in  bytes. 
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system  size  (oss)  represent;  the  number  of 
bytes  of  remote  fast  store  which  must  be  reserved  for  the 
operatinq  system  of  the  remote  CPU. 

For  each  remote  DPI!  a set  of  compatible  CPU^s  must  bu 
Listed,  and  a set  of  DPU  instruct i on s must  be  described. 

Compatipie  C£U^s  (CCT)  is  a qroup  whose  entries  are 
names  which  match  entry  names  from  the  remote  CPU  qroup. 
These  names  identify  those  CPU's  which  can  serve  the  qiver. 
DPH.  reasons  for  omission  of  a CPU  from  such  a list  a e: 
(1)  inadequate  software  support  tor  that  particular 
combination,  (2)  incompatible  word  l»nqths,  etc. 

DPU  ilSftlictcns  (DPI)  is  a qroup  whose  primary  purpose 
is  to  serye  the  hardware-software  tradeorf  capability 
(sec.  2.  i)  and  the  flicker  test  in  selective  specificaion 
(sec.  2.4) . Nevertheless,  this  qroup  also  provides  data 
which  allows  the  size  of  the  DP'J  proqrams  to  be  reflected  in 
the  allocation  of  remote  fast  store  and  allows  the  CPU 
support  of  'he  display  processor  to  be  reflected  in  remote 
store  allocation  and  response  time  calculations.  Each  DPU 
instruction  is  listed  by  name,  speoityinq  a series  of 
performance  attributes:  lH22£.m jnta  1 yost,  2£2£ad!ii.£ 

instruction  size,  CPU  time,  and  DPU  £im§.  These  attributes 
are  described  fully  in  section  2.  J.  wfe>n  not  involved  in 
ha  rd  wa  re- sof  twa  r*1  traieo'f,  DPU  instructions  ire  qiven  in  a 
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sinqle  "option",  and  assiqned  a zero  incremental  cost  (OIC) , 
since  they  are  not  separately  priced  from  the  DPU.  If  an 
instruction  does  not  require  CPU  intervention  for  its 
execution,  the  procedure  size  (OPS)  and  CPU  time  (OCPT) 
attributes  are  likewise  set  to  zero.  Instructions  can 
sometimes  be  aqqreqated  and  qiven  a class  name  and 
attributes  if  the  averaqe  value  of  these  attributes  does  not 
siqnif icantly  vary  from  DPU  to  DPU,  and  if  the  application 
description  file  data  is  similarly  aqqre jated. 

H2St_£0!2Ut££ 

Attributes  doscribinq  the  host  computer  are  fast  stgpe 
size,  bulk  sjore  size,  bulk  store  seek- latency  t ime.  bulk 
§ tO£§  transfer  time,  and  CPU  speed.  Since  only  one  host 
computer  is  considered  in  the  optimization,  neither  name  nor 
cost  data  are  supplied.  The  host  computer  is  assumed  to 
influence  only  the  response  time  as  its  hardware  is 
preconf iqured. 

fast  store  size  (FSS)  represents  th®  maximum  number  of 
bytes  which  can  be  occupied  by  proqrams  and  data  from  the 
application. 

Sulk  sfgpg  size  (3SS)  represents  the  number  of  bytes  of 
storaqe  available  in  th®  host  bulk  store. 

Bali  store  seek-fa t epc_y  time  (BSSL)  represents  the 
averaqe  seek/latency  time  ("access  time")  associated  with 
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the  host  hulk  store  facility,  in  seconds. 

Bulk  s t;  o re  transfer  time  ( B i'1  T)  represents  the  transfer 
time  per  byte  associated  with  the  host  bulk  stoLQ.  it  is 
measured  in  seconds  per  byfp. 

CPU  s.peed  (HSP)  represents  the  number  of  high  le  el 
instructions  per  second  that  the  host  processor  is  capable 
of  executing,  on  the  average.  Because  it  is  used  in 
response  time  calculations,  it  is  important  that  this  speed 
represent  the  capability  seen  by  a satellite,  suitably 
derated,  it  the  CPU  is  time-shared  to  account  for 
competition  from  other  iob  streams. 


■ 
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2.3  Hardware-Software  Tradeoff  Data 

The  hardware-software  tradeoff  features  allow  the 
optimizinq  proqrams  of  S AT MODEL  to  consider  hardware  options 
provided  by  the  manufacturer  of  a DPU.  These  options 
normally  take  the  form  of  instructions  which  are  supported 
in  hardware  that  miqht  otherwise  have  been  provided  by 
software  support. 

Usual  examples  of  such  options  deal  with  transformation 
hardware,  subroutine  lumps,  character  qenerations,  scalinq, 
etc.  Sine*1  not  every  user  will  he  interested  in  the  same 
sets  of  possible  options,  and  since  they  can  qenerally  be 
treated  in  a quite  standard  manner,  no  particular  options 
are  provided  automatically  in  the  file  or qan ization.  A user 
lists  the  options  to  be  considered,  usinq  suitably 
descriptive  names,  in  the  Instructions  subqroup  (DPUI)  of 
the  D£U  Ciiar actgristigs  qroup  (DPUC)  of  the  hardware  file. 
The  entries  (instruction  names)  used  are  identifiers  of  8C 
characters  or  less. 

Whether  the  instruction  is  supported  by  hardware  or  by 

) software  affects  both  the  performance  and  cost  of  the  DPU. 

Therefore  each  entry  in  the  Remote  DP'J  (DPU)  qroup  must 
i 

I contain  data  describinq  the  incremental  cost  and  performance 

attributes  of  the  alternative  options.  In  SATMODEL  no  more 
than  two  options  are  permitted  for  each  instruction. 
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The  DPU  entries  contain  a qroup  (DPUI)  of  instructions, 
identified  by  names  matching  those  provided  in  the  DPU 
Characteristics  group.  For  each  instruction  so  listed, 
there  are  one  or  two  options,  each  havinq  attributes 
specifyinq: 

1.  Incremental  cost  (QIC)  - the  cost  of  the  option  as 
an  add-on  to  the  DPU  cost  (DPC). 

2.  Procedure  size  (OPS)  - the  number  of  bytes  of  remote 
store  required  for  this  option  to  be  available, 
whether  or  not  it  is  actually  invoiced  by  lie- 
application. 

1.  Instruction  size  (OTS)  - the  number  of  bytes  of 

remote  store  additionally  required  for  each 
invocation  of  the  instruction  capability. 

h.  CPU  time  (OC PT)  - the  number  of  basic  CPU 

i nst ruction- time s which  the  execution  of  this  DPU 
instruction  will  require  ps-t  parameter  in  the 
invocation.  (The  aqqreqate  CPU  time  taken  by  this 
instruction  will  be  this  value,  divided  by  CPU  speed 
(CSP)  for  the  qiven  CPU,  multiplied  by  the  number  of 
invocations  of  this  instruction  and  multiplied  by 
the  number  of  parameters  per  invocation  - both  taken 
from  the  application  f i 1 ? . ) 

S.  DPU  time  (ODPT)  - the  time,  in. seconds,  which  t ho  I, i'll 
requires  p°r  parameter  in  the  invocation.  (The 
aqqreqate  CPU  time  t iken  by  this  instruction  will  be 


this  value  multipliel  by  the  number  of  invocations 


2.4  Selective  Specification  Data 

In  order  to  accomplish  selective  specification,  th  re 
needs  to  bo  a way  to  specify,  in  the  hardware  tile, 

performance  raea  surer,  which  do  not  directly  affect  response 
time.  Measures  such  as  resolution  for  a DP'J,  availability 
of  floating  point  or  ruqqe  lizaticn  for  a CPU,  01  access 
methods  (sequential,  direct)  for  a bulk  store,  must  be 

infered  somewhere. 

No  such  measures  are  explicitly  built  into  the  hatdw^r 
file.  Instead,  a series  of  fiv»  groups  (DLC,  FFC,  FBC, 
CPUC,  DPUC)  are  provided  in  the  file  so  that  a user  • a;: 
provide  names  for  each  sp^ci f ication  over  which  he  miqht 
wish  to  select.  Both  names  and  the  dimensional  units  by 

which  the  quantities  are  measured  must  be  specified  in  these 
supplementary  qroups.  These  name  entries  are  called 

characteristic  names  and  can  he  any  identifier  of  oO 

characters  or  less.  The  dimensional  units  are  attributes 
(DIM)  and  can  also  be  any  identifier  of  80  or  less 
characters . 


The 

values  of 

these  specification; 

for 

individual 

h a rd  ware 

I^ems  ate 

entered  via  the  basi'- 

data 

qroups  (DL, 

FFS,  PBS,  CPU,  DP")  , throuqh  th-'  SUPL’lefleLiwil 
Siiaiaciilistics  suhqroup  (DLSC,  F FSC,  PBSC,  CSC,  DPoC, 
respectively).  In  each  case,  the  value  is  qiven  by 
orovidinq  a chaj:a£i§I ist_ic  name  entry  which  matches  one  of 
the  characteristic  names  in  the  corr es oondin q characteristic 
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subqroup  (DLC,  RFC,  R DC , CPUC,  DPMC,  respectively)  and  then 
providing  an  inteqer  value  in  corresponding  va^ue  attribute. 

The  application  data  will  provide  a criterion  for 
selectinq  from  among  the  hardware  items.  Fach  hardware  item 
whose  value  in  one  or  more  listed  characteristics  fails  to 
exceed  the  criterion  will  be  excluded  from  the  optimization. 

The  application  data  will  also  provide  data  reqardinq 
typical  display  scenes  which,  when  used  with  DPU  instruction 
data  in  the  D£U  group  of  this  hardware  data  file,  permits 
calculation  of  display  flicker  rates.  These  are  also 
compared  with  a criterion  provided  in  the  application  file, 
and  may  cause  elimination  of  a DPU-CPU  pair  from 
consideration . 
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2. 5 An  Fxdmple 
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hardware  filc(lif) 
data  llnks(dl) 

12 uO  LiPd : 1 mi  1 o 

cost(ulc)-  90 

spoed(dlsp)=  144 

overhcad(dlo)=  0.01U435 
supplementary  character istics(dlsc) 
I)  i £ unco 

vulue(val)=  1 

4000  Lil’d:  1 mile 

cost(dlc)=  275 

speed(dlsp)=  575 

over(iead(dlo)=  0.002609 

supplementary  character ist ics(dlsc) 
Distance 

value(val)=  1 

2,000,000  3P3:  1 mile 
cost(dlc)=  405 

speed(dlsp)=  2500C0 
overheed(dlc)=  0.C0000E 

supplementary  character  ist  ics(dlsc) 
D i s tance 

value(val)=  1 

19200  3P3:  11  miles 
ccst(Jlc)=  950 

spcec!(dlsp)  = 2250 

ovcrhcad(dlo)=  0.00GGC7 

supplementary  character i st ics(dlsc) 
D i s tance 

value(val)=  11 

remote  fast  s tores (rfs) 

32k  ilytes  Extra  Core 
cost(rfcs)=  150 

siae(rfsi)=  32760 

supplementary  character ist ics( rfsc) 
Cycle  Time 

valuc(val)=  1020 

64!'  dytes  Extra  Core 
ccst(rfcs)=  340 

si2e(rfsi)=  05530 

supplementary  character i st ics( rf sc) 
Cycle  Time 

value(val)=  1020 


Figure  2.1  A Hardware  File 


112.C  Cyt.:s  E.xtrn  Con: 
ccst(rfcs)=  470 

sizo(  r f i. i )=  114C0C 

suppl  o'  ion  tar  y ci  .arac  ter i st i cs( r f so ) 
Cycle  Tinr 

valuc(val)=  1020 
roi.oto  hulk  stores(rhs) 
lull;!  p.i#.o, 

cost(  rbcs)=  275 

sizo(r!>si)  = 241/7000 

sock-latency  time(slt)=  0.070000 
transfer  tii.*:(trt)=  0.000000 
suppl ementary  character  i st  ics(  rhsc) 

Size 

value(v.il)=  -2407000 
remote  cpus(cpu) 

DOC  POP  11/40  with  Memory  Management 
cost(ccs)=  700 

speecJ(csp)  = 1C0C0 

;i«ximum  fast  store(mfs)=  131C72 
opera t inj1,  system  si/io(oss)  = 10304 

supplementary  character i st ics(csc) 
Access  Time 

value(vul)=  3300 

DOC  PC P 11/70 

oost(ccs)=  1050 
speodCcs!  )-  20000 

maximum  fast  store(nfs)=  131072 
operating  system  size(oss)=  1C3C4 

suppl er.cntary  cliaracterl  st  ics(csc) 
Access  Time 

va 1 ue(val )=  3300 

rer.ote  Jpus(dpu) 

VG  Geries  3 2D 

ccst(cJpc)  = 570 

compatible  cpus(ccp) 

DEC  PDP  11/40  with  Me:  rry  Mann  '.or  rent 
DEC  PDP  11/45 
DEC  PDP  11/4C 

DEC  PDP  11/45  with  Memory  Management 
PEC  PDP  11/ 70 


Figure  2.1  (continued) 
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instructions(dpi ) 

Sasic  Operation  Got 
Rc/;u  1 nr  Display 

incronental  cost(oic)=  0 

procedure  size(ops)*  0 

instruction  slze(ols)®  3 

epu  ti;ne(ocpt)=  0 

dpu  t ii.r?(o  !pt)=  0. 000014 

lii(,h  Speed  Display 

incremental  cost(oic)=  114 

procedure  size(ops)=  0 

instruct  ion  sizc(ois)=  3 

epu  time(ocpt)=  0 

dpu  time(odpt)=  0.000007 

Subroutine  Jump 
DPU  stnch 

increnental  cost(oic)=  0 

3 procedure  si.:e(ops)=  0 

instruction  size(ois)=  0 

epu  timc(ocpt)=  1 

dpu  t if.tiCo  !pt)=  0.000000 

Rotat  ion 

Rotation  Hardware  Option 

incremental  cost(cic)=  231 

procedure  size(ops)=  0 

instruction  size(ois)=  2 

epu  tiiie(ocpt)=  C 

dpu  t ii.r?(oJpt)=  0.000010 

Rotation  Software  Package 

incremental  cost(oic)=  £C 

procedure  size(ops)=  512 

instruction  size(ois)=  3 

epu  time(ocpt)=  2 


dpu  t ir,'.e(odpt)=  0.0C00G0 
supplementary  character ist icsCdpsc) 
rcsolut ion 

value(val)=  1774 

colors 

vnlue(val)=  1 

dimensionality  of  display 
vulue(val)=  2 

dpu  instruct ions(dpui) 

Subroutine  Jump 
Sasic  J;x:rution  Set 
Rotation 
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host  computer (he) 

instal  lotion  nar.ie(h:ii.i)=lJiiCCC  I ! V 1 310/75 
fast  store  size(fss)=  307200 
bulk  store  size(!>ss)  = 30720C0C 
bulk  store  seek- latency  tirie(bssl)  = 0.030400 

bulk  store  transfer  t ime(hstt)=  0.000001 
cpu  specd(hsp)=  10000 
data  link  character istics(dlc) 

!)i  stance 

dinx;nsions(dii,  )=  1i  les 
remote  fast  store  cl  aractcristics(rfc) 

Cycle  Time 

d irons i ons ( d im)  =;  ,enory  Cycles  per  ililli second 
remote  bulk  store  characteristics(rbc) 
oize 

dimensions(dim)=*i  locative  of  size  field  (rhsi ) 
cpu  character i sties (epue) 

Access  Time 

dinens ions(dii.i)=i‘JuMher  of  memory  accesses  per  millisecond 
dpu  characteristic  descript ions(dpud) 
dpu  character i st ics(dpuc) 
resolution 

dismris  ions  (dim)  =Lines  per  Inch 
colors 

dir.ens  ions  (din) =!Jiimher  of  Colors  (l=hlack  and  white) 
dimensionality  of  display 

dirt;nsions(dir:)=;ju'f'er  of  Coordinates  needed 

to  six'cify  a Point 
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CHAPTER  3:  APPLICATION  PR03R  API  DESCRIPTION 

In  this  section  we  explain  how  to  describe  an 
interactive  graphics  application  program  to  the  modelinq 
system.  The  file  editor  (FFD)  is  usad  to  insert  the 
description  into  the  application  proqram  description  file. 
He  first  describe  the  parts  of  the  description  needed  to 
perform  the  basic  optimization  process  of  desiqninq  a 
minimum  response  time  system,  then  discuss  hardware-software 
tradeoffs  and  selective  specifications,  in  that  order. 

3. 1 The  Basic  Optimization 

3.1.1  Description  of  Application  Proqram  Nodules 

The  system  designer  who  uses  SATNODEL  must  first 
organize  the  application  under  study  into  proqram  modules. 
This  modularization  is  essentially  the  first  step  toward  the 
actual  desiqn  of  the  application.  As  such,  it  must  be 
recoqnized  that  there  are  many  ways  any  given  application 
can  be  modularized.  The  designer  should  attempt  to  develop 
a realistic  modularization,  since  the  optimum  division  of 
labor  found  by  SATtlODF L will  be  ir.  terms  of  these  modules. 

The  level  of  detail  of  modularization  is  completely  at 
the  discretion  of  the  user.  A very  coarse,  first  level 
modularization  miqht  be  done,  or  the  final  detailed 
modularization  might  be  used  instead.  Th>*  graphics  package 
which  builds  and  modifies  DP'I  programs  and  handles 


r 
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interaction  devices  might  he  treated  as  a single  large 
module,  or  it  mi  r tit  be  further  broken  down  into  its 
consitituert  parts.  The  latter  option  would  be  necessary  it 
the  desiqner  were  considering  the  possibility  of  placing 
some  qraphics  package  functions  on  the  host,  and  others  on 
the  satellite.  However,  too  fine  a modularization  can 
result  in  very  long  execution  times  for  the  optiaiza  t i or: 
phase.  The  most  mod  ul  as  we  have  iealt.  with  is  about  40, 

! There  must  be  at  least  ou.  module  in  the  program 

description  Figure-  3.1  shows  . carse  mo  tu larization  uhi  h 
is  typical  of  many  interactive  graphics  applications.  The 
figure  is  the  standard  block  liajram  of  a graphics  program 
modularized  to  separate  lexical,  syntactic,  and  semantre 
processing . 
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The  detailed  information  required  for  each  module  is 
now  described.  For  reference  purposes,  we  qive  the  FED 


group,  entry 

and 

attri  but.e 

names. 

Module 

Name 

: qroup 

MOD,  entry 

Module  Name. 

Each 

program  module 

is  qiven 

a unique 

name  of  up 

to 

8C 

characters. 

This 

name  will 

be  used  in 

other  parts 

of 

t he 

application  description  to  refer  to  the  module,  as  well  as 
in  the  output  report  describing  the  optimal  division  of 
labor. 


Each  module  has  several  attributes,  all  of  which  must 
be  specified. 

Module  Size:  qroup  100,  entry  Module  Name,  attribute 
MSIZ.  This  is  the  actual  size  of  the  machine  code  and  local 
data  areas  for  the  module,  in  bytes.  Areas  of  I/O  buffers 
and  COMMON  or  EXTFFNAL  data  are  not  included.  In  most  cases 
the  designer  will  have  to  estimate  these  sizes,  unless  the 
application  already  exists  and  its  relevant  characteristics 
can  be  measure!.  In  practice,  module  sizes  will  vary 

somewhat  from  one  computer  to  another,  dependent  upon 
architectural  details.  The  planned  implementation  language 
for  the  application  must  also  be  considered,  since  compilers 
usually  produce  more  code  than  would  a clever  assembly 
lanquage  programmer. 

The  module  size  will  he  used  when  the  optimizer 
considers  different  divisions  of  labor.  For  instance,  some 
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modules,  or  combinations  thereof,  may  require  more  main 
memory  space  than  is  available  with  the  satellite  computer. 

flodulg  InstoctiQns:  qroup  MOD,  entry  Module  Name, 
attribute  MINS.  This  is  the  averaqe  number  of  instructions 
executed  each  time  the  module  is  invoked  (called).  The 
meaninq  of  the  word  '•instructions"  is  completely  at  the 
desiqner's  discretion,  and  miqht  equally  well  be  called 
"units  of  work".  These  units  can  be  thouqht  of  as  low-level 
primitives  such  as  add,  subtract,  text,  move,  etc.,  or  as 
hiqher-level  primitives  like  list  insertion  and  searchinq, 
sortinq,  or  addinq  up  a collection  of  numbers. 

The  instruction  counts  are  used  by  SATNODEL  to 
calculate  the  averaqe  execution  time  of  the  module 
(exclusive  of  all  I/O)  on  both  the  host  and  satellite.  In 
the  former  case,  a remote  computer's  speed,  in  instructions 
per  second  (or  work  units  per  second)  is  used;  in  the  latter 
case,  the  host  computer's  speed.  These  speeds  are  taker 
from  the  hardware  fil®.  It  is  thus  the  desiqner's 
responsibility  to  estimate  (or  measure)  the  instruction 
counts  and  speeds  so  that  correct  execution  times  are 
arrived  at  when  the  court  is  divided  by  the  speed. 

J3§na2emgQi;  qroup  MOD,  entry  Module  Name, 
attribute  THEM.  The  desiqner  can  specify  one  of  three 
different  memory  manaqement  alqorithms  to  be  used  with  each 
module  in  the  model  or  he  can  have  SATMODEL  select  the  best 


alqorithm.  The  latter  alternative 


however 


will  cause 


SATHODEL's  execution 
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SATHODEL's  execution  time  to  increase,  and  should  be  used 
only  with  considerable  reserve,  and  only  if  the  total  number 
of  optimization  variables  is  within  reason  (see  section  h . z 
on  optimization  performance).  We  suggest  that  initial 
optimizations  in  a system  desiqn  study  be  done  with  a single 
memory  management  alqorithm,  ami  that  optimization  over 
several  algorithms  be  considered  or.iy  in  the  later  stages  ui 
design. 


The  value  of  the  attribute  is  a character  string  of 
lenqth  between  one  and  three,  formed  from  the  characters  A, 
F,  and  W.  Mo  character  may  be  repeated.  Each  character 
refers  to  one  of  the  three  memory  management  algorithms.  If 
only  a single  character  is  liven,  the  corresponds nq 
algorithm  will  always  he  used.  If  two  or  three  are  qiven, 
the  optimizer  will  select  the  best  algorithm. 

The  character  A refers  to  a read  always  algorithm:  each 
time  the  module  is  invoked,  its  code  must  t>e  read  in  from 
backinq  stora.  This  roughly  corresponds  to  the  way  some 
overlay  systems  work  in  minicomputer  operating  systems. 

The  character  ? refers  to  the  permanently  resident 
algorithm:  the  nodule  is  always  in  main  memory,  so  invoking 
it  never  incurs  backing  store  overhead.  This  is  the  normal 
subsystem  of  usage  in  many  operating  systems  and 
applications.  Mote  that  the  no  lei  does  not  try  to  account 
for  the  time  taken  to  initialize  an  application,  a process 


which  would  of  course  involve  loading  main  memory  with  all 


35 


the  permanently  resident  modules. 

The  character  w refers  to  the  workinq  set  alqorithm.  A 
simple  probabilistic  model  is  usid  to  calculate  the 
probability  that  each  module  will  already  be  in  main  memory 
and  thus  reed  not  be  loaded  from  hackinq  store.  The 
probability  depends  on  the  frequency  of  use  of  each  module 
with  respect  to  other  modules,  the  total  size  of  all  modules 
beinq  manaqed  by  the  workinq  set  alqorithm,  and  the  amount 
of  main  store  available.  Details  can  be  found  in  the  fi£St 
Annual  Report  . The  intention  is  tc  model  virtual  memory 
. environments  such  as  those  of  the  IB*!  360/67,  qE  645,  PDP- 

1 1/45,  and  PDP-1 1/70. 

All  modules  are  allocated  backinq  store  space  for 
permanent  storaqe.  Resident  modules  are  of  course  assiqned 
space  in  main  memory  of  whichever  computer  they  are  assiqned 
to.  The  collection  of  read  always  modules  assiqned  to  a 
particular  computer  take  space  equal  in  size  to  the  larqest 
of  the  modules.  The  collection  of  workinq  set  modules 
assiqned  to  a particular  computer  requires  at  least  as  much 
space  as  th®  larqest  of  the  modules,  but  will  use  as  much 

p 

additional  main  memory  as  is  available,  up  to  the  sum  of  the 
sizes  of  the  modules. 

5i£e:  qroup  10D,  entry  Nodule  Name,  attribute  MSIT. 
For  each  proqram  module,  the  designer  indicates  one  of  three 
possibilities: 

0.  The  module  will  he  assiqned  to  a computer  site. 


* 

t 


either  host  or  satellite,  by  the  optimization 
algorithm. 

1.  Th.-  module  is  permanently  assigned  to  the  host 
computer. 

2.  Tne  module  is  permanently  assiqned  to  the  satellite 
conipu  ter. 

The  inteqers  0,  1,  and  2,  corresponding  to  the  three  above 

options,  are  the  three  permissable  values  for  M3IT. 

Options  1 and  2 would  be  used  tor  those  modules  wh:  ii 
must  be  executed  on  a specific  computer.  Massive  floating 
point  computations,  for  instance,  are  normally  done  by  the 
host  computer.  User  interrupt  handling,  DPU  program 
maintenance,  an  1 liqht  pen  correlation  are  usually  done  by 
the  satellite  computer.  The  number  of  modules  assiqned 
option  0,  the  so-called  free  modules,  has  a direct  bearing 
on  the  execution  time  of  3 AT  MODEL  (see  section  U.2  on 
optimization  performance).  The  most  free  modules  we  have 
ever  used  is  about  20. 

If  the  desiqner  knows  what  division  of  labor  he 
desires,  then  all  modules  would  be  fixed  to  the  host  or 
satellite  computer.  In  this  case  3ATMODEL  would  be  used  to 
find  the  appropriate  satellite  hardware  configuration  to  use 
with  the  specified  division  of  labor. 

IJsex.  Pgturn  .paramet  ei_L§n<jth:  group  MOD,  entry  Module 
Same,  attribute  PPL.  This  attribute  is  the  average  numbei 
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of  bytes  sent  by  the  nodule  to  an  output  device  (teletype, 
CRT,  etc.)  when  the  module  terminates  interaction.  If  the 
module  cannot  terminate  an  interaction,  this  attribute 
should  be  set  to  zero. 

I_£gtHfn_  Probability : qroup  MOD,  entry  Module  Name, 
attribute  R?F.  This  attribute  is  the  probability  that  this 
module  will  terminate  the  interaction  by  transferinq  control 
to  the  user,  rather  than  transferinq  control  to  another 
module. 

Within  each  Module  Name  entry,  there  is  a qroup  of  zero 
or  more  File  References  which  qive  information  concerninq 
module  I/O  activity.  A more  detailed  description  of  how  to 
describe  files  is  in  a later  section.  We  specify  the  names 
of  each  file  actually  accessed  by  a module,  a count  of  read 
accesses,  and  a count  of  write  accesses. 


£ile_Nam2:  qroup  MOD,  entry  Module  Name,  qroup  FF, 
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try 

File 

Name. 

This 

is  a unique  charact 

=r  strinq 
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Module  Name, 

qroup  FF 

9 

entry 

Fi 

le 

Name, 

attri 

bute 

WA. 

This  is  t h" 

same  as  t 

he 

F eads 

attribute,  but  tor  writes 


As  w i i J b.:  seen  in  a later  '.<ioi.e  detailed  discussion,  a 
file  raiqht.  be  either  a larqe  aqqreqate  of  data  items,  or 
lust  a few  specific  pieces  of  data. 

Within  each  Mod  .le  Name  entry,  there  is  also  a qroup  of 
Transfers  which  qive  informal  ior  concerninq  what  other 
modules  are  i rinsfprred  to  by  this  module.  We  specify  the 
name  of  e ach  module  actually  trail  terred  to,  the  probability 
of  the  transfer,  and  the  amount  or  information  transferred. 
A transfer  can  h<=  a subroutine  call  or  return,  or  even  a 
simple  iump. 

To  JjOdijle  Name;  qroup  MOD,  n try  Module  Name,  qroup 
"Tansfers,  entry  to  Module  Name.  The  name  of  another  module 
to  which  this  modulo  transfers  control. 

4 1 i t y : qroup  mod,  ^r.try  Module  Name,  qroup 
Transfers,  entry  To  Module  Name,  attribute  PR.  The 
probaoility  that  a transfer  occurs  from  the  entry  Module 
Name  to  th»  entry  Tg_Mgdule  Name  . Only  transfers  with  non- 
zero  probability  need  be  qiven.  "T'he  probabilities  in  the 
entry  Module  Name  must  sum  to  1.0. 

£aramt:tjr  Lsnath:  qroup  MOD,  entry  Module  Name,  qroup 
Transfers,  ^ritry  to  Module  Name,  attribute  PL.  The  averaqe 
number  of  bytes  of  parameters  passed  trom  Modu lg.ijame  tr,  Jo 
Mojulg  Name  wh  ;n  the  tLanfer  of  control  occurs.  Tt  the  two 
modules  ac«  or.  liff°rent  computers,  this  is  the  lenqth  of 


39 


the  messaqe  sent  between  the  computers.  The  lenqth  is  used 
to  calculate  the  time  needed  to  send  an  invocation  messaqe 
from  a calling  module  on  one  computer  to  the  called  module 
on  the  other  computer. 


3.1.2  Description  of  Aoplication  Proqram  Files 

Just  as  the  proposed  (or  actual)  application  proqram  is 
subdivided  into  modules,  so  the  application’s  data  base  is 
subdivided  into  files.  Of  course,  there  need  not  be  any 
data  base,  in  which  case  this  qroup  is  empty.  A data  base, 
in  the  qeneral  sense,  is  a collection  of  one  or  more  data 
items.  A file  may  be  as  larqe  as  the  data  base,  or  as  small 
as  a sinqle  data  item  in  the  data  base.  it  is  possible  that 
files  contain  duplicate  information. 

While  one  miqht  conceivably  divide  a 10  item  data  base 
into  10  files,  ioinq  so  would  serve  no  useful  purpose.  Data 
bases  are  usually  subdivided  into  a few  files,  with  all 
items  in  a particular  file  often  beinq  related  or  similar  to 
one  another  in  specific  ways.  The  number  and  nature  of 
these  files  is  established  durinq  the  application  desiqr 
process.  As  with  modules,  the  level  of  detail  in  the  file 
structure  is  entirely  at  the  dosiqner's  discretion.  The 
more  files  used,  however,  the  more  t ime-consuminq  the 
optimization  process.  Each  file  has  an  entry  in  the  FILF 


qroup: 
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File  Name:  group  FILE,  entry  File  Name.  Each  file  is 
given  a unique  name  of  up  to  80  characters.  Each  file  Las 
several  attributes,  all  of  which  must  be  specified: 


By£f‘jr  Size:  qroup  FILE,  entry  File  Name,  attribute  Bb. 
This  is  the  size,  in  bytes,  of  the  buffer  needed  to  access 
the  file.  This  would  normally  be  the  physical  record 
lenqth,  or  block  size,  of  the  file. 

Total  Size:  group  FILE,  entry  File  Name,  attribute 
The  maximum  size,  in  bytes,  of  the  file.  This  is  the  amount 
of  bulk  storage  space  which  will  be  set  aside  for  the  file. 
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Access:  group  FILF,  entry  File  Name,  attribute  JU.C. 
This  is  a character  string  of  length  one  which  indicates  ho>. 
the  file  is  accessed.  An  S means  serial  access,  for  which 
anticipatory  input  buffering  is  modeled  if  more  than  one 
buffer  is  avaialble  for  the  file  (see  Buffer  Number  belo  ) . 
On  output,  with  more  than  one  buffer,  overla ppe d output  and 
program  execution  is  modeled. 

An  F,  means  a random  access  tile,  in  which  case  no 
anticipatory  buffering  or  overlapped  output  is  attempted. 

Buft.er  Management:  group  PILE,  entry  File  Name, 
attribute  Btt.  The  designer  can  specify  one  of  three 
algorithms  wi*-h  which  the  file's  buffers  are  to  be  managed, 
or  can  have  SATMODKL  select  the  best  algorithm.  But  -just  as 
with  memory  management  for  algorithms,  the  latter 
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optimization  algorithm s. 

The  value  of  the  attribute  is  a character  strinq  of 
lenqth  between  one  and  three,  formed  from  the  characters  A, 
P,  and  W.  No  character  may  be  repeated.  Bach  character 
refers  to  a specific  alqorithm.  If  a sinqle  character  is 
qiven,  the  correspondinq  alqorithm  wilL  always  be  used.  If 
two  or  three  are  qiven,  the  optimizer  will  select  the  best 
alqorithm . 

The  character  A refers  to  an  Allocate  a 1 w alqorithm. 
Buffer  space  is  allocated  before  each  I/O  operation,  then 
released  afterwards.  This  means  that  main  memory  space  is 
not  permanently  dedicated  to  buffers  for  the  file. 

The  character  P means  Resident  buffers.  Buffers  are 
permanently  allocated,  and  do  take  main  memory  space.  Most 
operatinq  systems  use  this  approach. 

The  character  w means  Wo^kiaa  set  buffers.  A buffer 
will  be  in  main  memory  unless  "swapped  out",  or  deallocated, 
in  favor  of  the  buffer  for  a more  recently  or  frequently 
used  file. 

Number:  qroup  FILB,  entry  File  Name,  attribute 
3N.  The  maximum  number  of  buffers  (each  of  size  qiven  by 
the  Buffer  Size  attribute)  allocated  for  this  file.  This 
number  is  iqnored  if  a buffer  manaqement  alqorithm  of 
Allocate  always  is  in  use.  There  is  no  reason  to  specify 
more  than  one  buffer  for  direct  tiles;  as  their  use  is  not 
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modeled. 

Site:  jroup  file,  entry  File  Name,  attribute  PS  T 

This  is  interpreted  in  the  same  way  as  attribute  MSIT  tor 
program  modules.  A value  of  0 means  the  optimum  silo 
assignment  is  to  be  found;  I,  the  file  will  be  at  the  host 
CPM;  2,  th(  file  will  bo  at  the  satellite  CPU. 


3.2  Hardware-Software  Tradeoffs 


The  hardware-software  tradeoffs  examined  by  S ATHODEL 
have  to  do  with  the  implementation  of  display  operations. 
The  applications  file  includes  a description  of  all  display 
operations  used  by  the  application,  and  some  basic 
information  associated  with  the  operations.  If  the  system 
desiqner  is  not  interested  in  examininq  hardware-software 
tradeoffs,  most  of  the  information  described  here  need  not 
be  qiven.  Some,  however,  is  reeded  if  a flicker- free 
display  capacity  is  specified.  All  information  needed  for 
this  purpose  is  so  indicated. 

The  display  operation  set  has  one  entry  per  display 
operation.  Each  operation  beinq  considered  for  the 
hardware-software  tradeoff  would  be  included.  Also,  if 
flicker-free  display  capacity  is  of  interest,  a basic 
display  operation  such  as  "draw  picture  primitives"  raiqht  be 
defined,  althouqh  this  could  be  instead  represented  as 
separate  operations  for  each  of  the  primitives  such  as 
points,  lines,  and  text. 

The  order  in  which  the  hardware-software  tradeoffs  are 
considered  is  the  order  in  which  the  display  operations 
occur  in  this  qroup.  Since  FED  inserts  only  at  the  end  of 
qroups,  chanqinq  the  order  requires  deletion  and  re-entry  of 
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Q£^I3iion  Name:  qroup  DOS,  entry  Operation  Name.  The 
name  is  a strinq  of  up  to  8D  characters.  The  name  must 
match  a nam^  in  the  instruction  set  list  of  each  fcemote  DPb 
in  the  hardwar®  file.  Throe  attributes  are  given  with  each 
entry  in  the  DOS. 

PiI§S&irI  Length:  qroup  DOS,  entry  Operation  Nauw, 
attribute  opL.  This  is  the  average  number  of  bytes  or 
information  required  by  the  display  operation  each  time  it 
is  invoked.  For  instance,  a simple  draw  instruction  in  a 2- 
1-  DP U would  need  2 bytes  for  an  x coordinate,  and  2 bytes 
for  y.  A rotate  instruction  requires  a rotation  matrix  plus 
all  the  coordinates  which  will  be  rotated.  A draw  text 
instruction  requires  one  byt-^  per  character. 

I 

If  th*.  application  proqram  module  which  invokes  the 
display  operation  is  executing  on  the  host,  this  is  the 
number  of  bytes  which  will  h*  sent  to  the  satellite  to  cause 
the  operation  to  be  performed. 

Site:  qroup  DOS,  entry  Operation  Name,  attribute  OSIT. 

This  attribute's  value  is  currently  iqnored  by  SATMODKL, 
havinq  h»p[,  included  for  future  expansions,  a value  must  bo 
specified.  The  implementation  of  a display  operation,  be  if 
in  hardare  or  software,  is  forced  to  be  at  the  satellite. 

The  leqal  values  of  th«  attribute  are  0,  1,  or  2.  Their 
interpretations  are  the  same  as  for  module  and  file  site 
attributes. 
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Memory  Management:  qroup  DOS,  entry  Operation  Name, 
attribute  OMEM.  This  attribute's  value  is  iqnored  by 
S ATMODEL , but  a value  must  be  specified.  The  proqram  aoaule 
used  to  implement  the  display  operation  is  assumed  to  be 
permanently  resident  in  main  memory.  The  attribute  value 
must  be  a character  strinq  of  lenqth  1 to  3 containinq  no 
more  than  one  occurence  of  each  of  the  letters  R,  A,  and  W. 
The  character's  interpretations  are  the  same  as  for  module 
memory  management. 


Sisplai  Operations;  group  MOD,  entry  Module  Name,  Group 
DO.  within  each  Module  Name  entry,  there  is  also  a group  of 
Display  Operations.  One  purpose  of  this  qroup  is  tc  allow 
the  optimizer  to  account  for  the  degradation  of  satellite 
CPU  performance  caused  by  asynchronous  user  interactions. 
For  instance,  in  a 3-D  drawing  application,  the  user  might 
have  a "joystick  to  control  the  viewinq  anqle.  Movinq  the 
"joystick  causes  the  object  displayed  on  the  screen  to 
rotate,  whether  or  not  other  processing  is  occurring  on  the 
satellite.  If  other  processing  is  indeed  takinq  place,  we 
assume  that  it  has  lower  priority  than  the  computations 
required  to  effect  the  rotation.  The  question  of  hardware- 
software  tradeoffs  comes  in  here:  if  the  rotation  is  carried 
out  in  hardware,  there  will  be  less  CPU  performance 
degradation  than  if  software  rotation  is  necessary.  Some 
applications  miqht  not  require  or  allow  this  sort  of 
concurrency,  in  which  case  the  qroup  of  display  operations 
would  not  be  used  in  this  way.  The  display  operation  group 
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is  also  uKr  1 to  account  for  CPU  performance  degradation 
caused  by  per fornin^  some  display  operations  in  CPU  software 
rather  than  in  DPU  hardware,  as  pail  of  th<  regular  refresh 
process.  Performing  subpicture  calls  with  CPU  aid  is  an 
exam  pie . 

Another  purpose  of  the  display  operations  is  to 
directly  account  for  the  effect  of  hardware-software 
tradeoffs  or.  response  time.  for  all  display  operations 
which  might  ne  implemented  in  -it  her  hardware  or  software 
and  which  in*,  module  directly  calls,  the  designer  specifies 
how  many  times  such  operations  are  called. 

Name : qroup  MOD,  entry  Module  Name,  group  DO, 
entry  Operation  Name.  This  is  the  char acter-strinq  name 
(maximum  length  #0)  of  the  display  operation.  The  name  must 
match  a name  in  the  Display  Operation  Set  qroup,  described 
above.  This  entry  has  iust  one  attribute: 

QE§£3li<=!U  Count  : qroup  MOD,  entry  Moiule  Name,  group 
00,  entry  Operation  Name,  attribute  DOC.  This  count  is  the 
sum  of  three  quantities.  The  first  is  the  number  of  times 
this  display  operation  is  invoked  asynchronously  by  user 
actions  each  time  the  module  is  active;  the  second,  the 
number  of  times  this  lisp! ay  operation  is  invoked 
asynchronously  is  part  of  the  DPU  tefresh  cycle  each  time 
the  module  is  active;  the  thiri,  the  number  of  times  this 
display  operation  is  iirectlv  callad  by  the  moiule,  each 


time  the  module  is  active 
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3.3  Selective  Specifications 

3.3.1  Flicker- free  Display  Requirements 

The  application  desiqner  can  describe  how  complex  the 
pictures  to  be  drawn  are,  and  how  fast  the  refresh  rate  must 
be.  SATNODEL  then  discards  those  D°Us  which  are  too  slow  to 
display  the  pictures  f 1 ic ker- free . The  description  is  of 
individual  pictures.  The  desiqner  should  describe  the 
larqest  pictures,  since  they  take  the  lonqest  to  display. 

For  purposes  of  conceptual ization , each  picture  is 
described  as  a series  of  subpictures,  each  with  one  or  more 
occurences,  of  course  a picture  may  contain  -just  one 
occurrence  of  one  subpictur°. 

fii£k££  Tolerance:  qroup  RFQ,  attribute  FL.  This  is 
the  minimum  refresh  rate,  in  frames  per  second,  needed  to 
draw  a flicker-free  picture  with  the  phosphor  selected  for 
'.he  application. 

Display  Usage:  qroup  HEQ,  qroup  DtJ . "'his  is  a qroup  of 
pictures.  Each  picture  has  a name,  and  one  or  more 
subpicturos. 

J?i<- turg  N§»e:  qroup  PRO,  qroup  DU,  entry  Picture  Name. 
A strinq  of  up  to  8 characters. 


Subpicture  Naa§:  qroup  BEQ,  qroup  DU,  entry  Picture 
Name,  entry  Subpicture  Name.  A strinq  of  up  to  80 


* 
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characters 


5ultio).  i cj  ty:  qroup  FTy,  qroup  DO , entry  Picture  Ha  iar 
•entry  Subpicture  Name,  attribute  SHUL.  The  number  of  times 
this  subpi.t ure  occurs  in  the  picture  beinq  described 

QfiS Si'  ns:  qroup  T-v y,  qroup  Dll,  entry  Picture  Nau«  , 

> ntry  Subuii  tur*.  Name,  qroup  pop.  The  lisp] ay  operation 
used  by  the  subpicture  beinq  described. 

i i ii-Ii  Naje:  qroup  Rcy,  qroup  on,  entry  Pic  c 
Name,  entry  Subpicture  Name,  qroup  POP,  entry  Opera t o.' 
Name.  The  name  must  also  occur  in  t h®  instruction  set 
iescriptioi  for  each  DPI!  in  the  hardware  file. 


Hultiplicitv:  qroup  RHy,  qroup  D'l,  entry  Picture  Nane, 
entry  Subpicture  NAme,  qroup  POP,  attribute  POM.  The  number 
of  times  the  operation  occurs  in  the  subpictures  beinq 
1 e sc  r i be  d . 

The  time  taken  to  draw  a particular  picture  is  the  sum 
of  the  times  taken  to  draw  each  instance  of  each  subpicture, 
"he  maximum  time  to  draw  any  of  the  picutures  is  compared  to 
the  refresh  ate  +o  determine  whether  the  OPU  is  acceptabJe. 


The  t i in"  taken  to  draw  a suhpwture  is  the  sum  of  the 
times  need"  i to  execute  each  invocation  of  each  display 
operation.  These  times  are  taken  from  the  hardware  file. 
Tf  a display  operation  has  two  implementations  (hardware  «.nd 
software),  the  lesser  of  the  two  times  is  used  here. 
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3.J.2  Central  Selective  Specification 

Each  hardware  subsystem  (Data  Link,  Peraote  Fast  Store, 
Pemote  Bulk  Store,  Satellite  CPU,  DPU)  in  the  hardware  file 
can  have  an  associated  set  of  supplemental  characteristics, 
for  use  in  selective  specification.  These  characteristics 
raiqht  be  resolution  and  spot  size  for  the  DPU,  error  rate 
for  the  Data  Link,  etc. 

This  optional  section  of  the  application  file  is  used 
to  qive  the  minimum  acceptaol«  values  for  each  such 
supplemental  characteristic.  A subsystem  whose  value  is 
qreater  than  or  equal  to  the  mimiaum  will  be  accepted  and 
considered  in  the  optimization  process;  els®,  it  is  relected 
and  not  consi lered  further.  Also,  if  the  supplemental 
characteristic  is  missinq  from  a subsystem's  description, 
the  subsyt«m  is  discarded. 

Since  th“  acceptance  test  is  "qreater  than  or  equal 
to",  supplemental  attributes  like  spot  size  (where  a smaller 
value  is  better  than  a larqer  value)  must  be  specified  as  an 
inverse,  i.e.,  1/inches  rather  than  inches.  Also,  non- 
numeric attributes  such  as  half-duplex  and  full-duplex  must 
be  numerically  coded  in  order  of  increasinq  preference, 
i.e.,  1 = half-duplex,  2 = full-duplex. 


Se lecti ve 
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than  same  mimimum  are  to  be  considered,  the  speed  must  be 
duplicated  as  a supplemental  characteristic,  even  though  it 
also  appears  as  a data  link  attribute. 


Th»  groups  DLS,  RFSS,  PBSS,  CPUS,  and  DPUS  are  used  to 
qive  the  supplemental  characteristics  names  (as  an  entry) 
and  minimum  value  (as  an  attribute  under  the  name). 
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3.4  User  characteristics 

Two  user  characteristics  are  of  importance:  the  averaqe 
think  time  (time  between  interactions)  and  the  probability 
distribution  of  initial  program  module  activation  caused  by 
user  interactions.  These  characteristics  must  be  included 
in  the  application  proqram  description. 

ysefthink  Jimg:  qroup  USER,  attribute  UTT.  The  user 
think  time,  in  seconds. 

User  Hodule  References:  qroup  USFF,  qroup  UHR.  A list 
of  all  proqram  modules  which  might  be  directly  activated  by 
a user  action.  These  are  the  modules  which  actually  wait 
for  a user  action  (pen  hit,  character  string  input,  etc.) 
In  many  applications,  there  is  only  one  such  module. 

£§fSI§ice^  32dulg  Name:  qroup  USE?,  qroup  UtlR , entry 
Referenced  Module  Name.  The  name  of  such  a module.  The 
name  must  match  that  of  application  proqram  module. 

Probability:  group  USEF,  group  U*!P,  attribute  UPP.  The 
probability  that  this  module  is  the  first  module  activated 
by  a user  action.  The  probabilities  for  all  modules  in 
group  UNF  must  sum  to  1.0. 

£afa me ter  Length_:  group  USEF,  group  UNR,  attribute 
UPL.  The  number  of  bytes  and  information  passed  by  the 
system  software  to  the  module.  Tf  the  module  is  host- 
resident  then  this  is  the  length  of  the  message  sent  accross 
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the  data  link,  to  the  nodule. 
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3.5  Example 

H, 

v Fiqure  3.2  is  a block  diaqram  of  the  nodules  and  files  used 

to  aodel  the  application  proqraa  of  fiqure  3.1. 

Fiqure  3.3  is  the  listinq  of  an  application  file  for  the 
proqraa  shown  in  fiqure  3.2.  It  is  desiqned  for  a basic 
optimization,  without  reqard  for  selective  specification  or 
hardware-software  tradeoffs. 

Fiqure  3.4  is  a copy  of  the  application  file  in  fiqure  3.3 
which  has  been  aodified  to  study  hardware-software  tradeoffs 
and  to  use  selective  specifications.  It  has  been  aqaented 
(in  places  aarked  by  an  • *•)  to  allow  hardware-software 
' tradeoffs  for  subpicture  subroutine  -jumps,  rotation,  and 

basic  operations.  It  also  provides  infornation  for 
selective  specifications  on  the  basis  of  flicker-free 

« 

display  capacity  and  the  suppleaented  characteristics  for 
each  of  the  subsystems.  The  files  shown  in  fiqures  3.3  and 
3.4  are  conpatible  with  the  hardware  file  shown  in  fiqure 
2.1. 
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application  file(af) 

display  operation  set(dos) 
requi remcnts(  req) 

flicl;er  tolorance( f 1 )=  0.000000 

display  usage(du) 
data  link  specif ications(dls) 
renote  fast  store  specif ications(rfss) 
renote  bul!'.  store  specif ications(rbss) 
epu  siiccif ications(cpus) 
dpu  specif icat ions (dpus) 
rnoJules(iTod) 
syntax 

sizc(msiz)=  10240 

instruct  ions(rn  ins)  = 100.000000 

menory  .iianagement(r.i  em)=w 
site(msit)=  0 

user  return  paraneter  lengtl  ( rpl )=  0 

user  return  probabi 1 i ty( rpr)=  O.OCCOOO 
file  references(fr) 
appdb 

rcads(ra)=  0.200000 

writes(wa)=  0.200000 

piedb 

rends(ra)=  0.  L0GG00 

writes(v;a)=  0.300000 

transfers(  tr) 
lexgp 

probabi 1 i ty(pr)=  0.  5C000 

parameter  lengthCpl )=  250 

semantix 

probabi 1 ity(pr)=  0.200000 

parameter  lcngth(pl)=  2000 

lexapp 

probabi 1 i ty(pr)=  0.450000 

parameter  longti\(pl  )=  250 

display  operat ions(do) 
lcxp.p 

size(msiz)=  1000 

instructions(mins)=  100.000000 
rneriD  r y manager len  t ( i irnem)  =w 
si  te(,-nsi  t)=  2 

user  return  parameter  lengthC  rpl  )=  10 

user  return  probab M i ty( rpr)=  0.500000 
file  references ( f r) 
cortbl 

reeds(ra)=  0.500000 
writes(wa)=  0.100000 


Figure  3.3  A Basic  Application  File 
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transfers( tr) 

SUiVillt  i x 

protab  i 1 1 ty(pr)=  0.C5GOOO 

parameter  1 en^th(  p I ) = 250 

syntax 

protabi 1 1 ty(pr)  = O.lGvOuO 

parameter  lenntMp]  ) = 250 

lexapp 

protab  I II ty(pr)  = 0.200000 

parameter  lenRth(pl)3  100 

dpucomp 

probobi  1 i ty(pr)  = 0.100000 

iwramoter  1nnr,tli(pl  ) = 50 

xfornicp 

probobi 1 ity(pr)=  0.050000 

parameter  lengtli(pl)3  500 

display  opcrations(do) 
xfonoup 

size(i.siz)  = 30720 

instruct  ions(mins)3  300. 0000C0 

memory  nanageriont(i  iin?r i)  =w 

si  te(r.,si  t)=  2 

user  return  pa  rare  ter  1 on>;th(  rpl ) = 

user  return  probnbi 1 i ty( rpr)=  C. 000000 

file  r<.ferences(f  r) 

transfersC tr) 

] (,'X.lpp 

probabi 1 i ty(pr)=  O.luOOOG 

parameter  lenr.tb(pl)-  50 

lcxrp 

probobi 1 i ty(pr)=  C.1G0000 

parameter  lenRth(pl)=  50 

dpucorip 

probobi 1 i ty( pr)=  0.300000 

parameter  lcnsth(pl)3  100 

traverse 

probabi 1 i ty(pr)=  0.  00000 

paruretcr  lonr;th(pl)  = 500 

display  ope rat  ions (do) 
dpucorip 

size(rnsiz)3  1C432 

instructions(i.ins)  = 3CO.GOGOOO 
memory  m.ino;;encnt(;a  )=v: 
si  tu(rnsi  t)3  2 

user  return  parameter  leiv;th(  rpl )- 
user  return  prolxib i 1 i ty( rpr)=  O.OOOOCO 
file  refercncos(fr) 
cortbl 

rou«'s(ra)=  1.500000 
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transferee  tr) 
lexapp 

probabi 1 i ty(pr)=  0.300000 
parameter  len^tli(pl)=  100 

1 exnp 

probabi 1 i ty(pr)=  0.400000 

parameter  1en;;tl;(pl  ) = 100 

xforn^p 

probabi J i ty(pr)=  0.300000 

parameter  lenj;tb(pl)  = 100 

display  oporat ions(do) 
t reverse 

size(:nsiz)  = 5120 

instruct  ions(mins)=  300.000000 
memory  r.iana;;emen t ( ; nem)  =w 
site(msit)-  0 

user  return  parameter  lenrth(rpl)= 
user  return  probabi 1 i ty( rpr)=  0.CG0000 

file  references(fr) 
p i cdb 

reads(ra)=  10.000000 
v.rites(wa)=  O.ClOrCO 
transferee  tr) 
xfor:  lpip 

probabi 1 ity(pr)=  1.000000 
parameter  lenr,tb(pl  )=  50 

display  operat ions(do) 
iexapp 

size(i.isiz)=  5120 

instruct  ions (mins) = 50.000000 

memory  mann ;;cmen t ( nner  )=w 
site(msit)=  0 

user  return  parameter  lenr.tb(  rpl  ) = 
user  return  probabi 1 i ty( rpr)=  O.OCOCOO 
file  references(fr) 
transfors( tr) 
scran  t i x 

probabi 1 ity(pr)=  0.200000 

parameter  lenp.t!i(pl )=  50 

syntax 

probabi 1 i tyf pr)=  0.200000 


parameter  1enrtb(pl)=  50 

1 ex;;p 

probabi 1 i ty(pr)=  0.400000 

parameter  lcnr;ti  (pi  )=  10 

!pucor  ip 

probabi i i ty(pr)=  0.3)0000 

parameter  len:;t!  (pl  )=  10 

xforrvip 

probabi 1 ity(pr)=  0.100000 

parameter  lon.rt!.(pl  )=  20 

di splay  o|x?rat  ions(do) 

Figure  3.3  (continued) 


0 


SC"  VMltix 

size(  i ^ ) = j120C 

instructions^  .ins)  = 500.000000 

i!»?  ory  ; •»inar.cr.x:nt(i  i c:  )=\/ 
sitc(,,sit)  = 0 

user  return  jjoriivotor  rpl  ) = 

user  return  probabi  I i ty(  rpr)  = 0.0 OUOOO 

file  referenccs(fr) 
appdh 

rcacis(ru)  = 0.  iOGGJG 

wr i tes(v:a)=  0.  SG0000 

pied b 

rends ( re)  = 0.4CCG0G 

wri  tcs(v.n)  = 0.20000C 

trensf  ors( tr) 
syntax 

p robot)  i 1 i ty(pr)=  0.7130000 

pnrnnetcr  le:t?.tl  (pl  ) = 2C0 

lexpp 

proUibi 1 i cy(pr)=  0. 100000 

parameter  lcn?;tb(pl  )=  50 

lexapp 

probabil  ity(pr)=  0.150000 


jxirorneter  lcn.t;tli(pl  ) = 
display  oporat ions(do) 
fi  les(f i lc) 


50 


buffer  siza(tn>)=  5120 
nurober  of  l)uffors(bn)  = 
total  size(ts)=  102400 
access (ncc)=r 
buffer  nnnnpor ent(b  )=a 
sitr(fsit)=  1 

piedb 

puffer  size(!>s)  = 5x20 

nunlior  of  buffcrs(  !>;,)  = 
total  size(ts)=  51200 

t.ccess(acc)=r 
buffer  r\ma/:onent(b;  0=w 
site(fr.it)=  2 

cortbl 

buffer  size(bs)=  5x20 
nu:i',)or  of  'auffers(t;ii)  = 
total  size(ts)=  20400 

access (ncc)=r 
buffer  rvina.tetrentCb.  )=// 
si  te( fsi t) = 2 

user (user) 


user  tl.inl;  ti..x.’(utt)  = 


’> . 70uu0U 


user  nodule  refe  reacts  ( u.r) 

1 expp 

probnbi  1 i ty(upr)  = 1.  G0CC00 

pnrneler  lenr.thfupl  ) = 00 

Figure  3.3  (continued) 
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application  filo(af) 
modules (mod) 
syntax 

size(i.isiz)  = 10240 

instruct ions(mins)=  ICO. 000000 
memory  mana/ierrent(rrrer)  =w 
si  toG.isi  t)  = 1 

user  return  parameter  lcnjjtli(rpl  ) = 0 

user  return  probabi 1 i ty( rpr)=  0.000000 
file  rcferences(fr) 
appdb 

reads(rc)=  C. 200000 

writes(wa)=  0.200000 

piedb 

reads ( ra)=  0.  LC0000 

wri tes(wa)=  0.  100000 

transfersC  tr) 
lex^p 

probabi 1 ity(pr)=  0.  50000 
ixjrareter  lenr.th(pl)=  250 

servant  i x 

probabi 1 i ty(pr)=  0.200000 

parameter  len»:th(pl)=  2000 

lexapp 

probabi 1 i ty(pr)=  0.450000 

parameter  lennthCpl )=  250 

display  operat ions(do) 
lexgp 

size(msiz)=  1CC0 

instruct  ions (mins)  = ICO. LC0000 
memory  manaserentOn  mi  ')  =w 
site(nsit)=  2 

user  return  parameter  lenr,th( rpl  )=  |0 

user  return  probabi 1 i ty( rpr)=  0.500000 
file  referencesCf r) 
cortol 

rr.ads(ra)=  0.5UG0G0 
writes(wa)=  0.100000 
transfors( tr) 
sci  lant  i x 

probabi 1 i ty(pr)=  0.050000 

parameter  len.’,th(pl)  = 250 

syntax 

probabi 1 i ty(pr)=  0.100000 

pa  rare  ter  lon;;tb(pl)=  250 

lexapp 

probabi 1 i ty(pr)=  C.20000C 

parameter  length (pi  )=  ICO 

dpuconp 

probabi 1 ity(pr)=  0.  X0000 

parareter  len,rth(pl  )=  50 

xforr.inp 

probabi 1 i ty(pr)=  0.050000 

parareter  lenrtKpl )=  500 

display  oierat  ions(do) 

Figure  3.4  An  Application  File  with  Hardware-Software  Tradeoffs 
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xformgp 

si^c(iiisiz)=  30720 

instruct  ions  (ill  ins)  = 300.000000 

menory  management (hi  mr ,)  =\i 
si tc(msi l)=  2 

user  return  parameter  longtK  rpl  )=  0 

user  return  probabi 1 i ty( rpr)=  0.000000 
file  refrronces(f r) 
transfers( tr) 
lcxapp 

probabi 1 i ty ( pr ) = 0.100000 

parameter  lengtli(pl  )=  30 

lexgp 

probabi 1 i ty(pr)=  0.100000 

l>irameter  longtMpl  ) = 3C 

dpucorip 

probabi 1 i ty(pr)=  0.300000 

[xiraneter  leiigtli(pl  ) = 10C 

traverse 

probabi 1 i ty(pr)=  0.500000 
parameter  lcn.;tb(p1  ) = 500 

display  opera t ions (do) 
llpUCOnp 

sizc(msiz)=  10032 

iristructions(niins)  = 300.000000 

inerory  monagenentC.Tiom)  =v: 
si  te(r,isi  t)=  2 

user  return  parameter  length ( rpl )=  0 

user  return  probabi 1 i ty( rpr)=  C.OC000C 
file  rcforcnces(fr) 
cortbl 

reads(ra)=  l.SuOOOO 
urites(v.a)  = 2.500000 

uransfers( tr) 
lexapp 

probabi 1 i Ly(pr)-  0.  L0C000 

parameter  lengtMpl  ) = ICO 

lcxgp 

proUibi 1 i ty(pr)=  0.4CG000 

parameter  1 *:nr.t!  ( j >1 ) = ICO 

xforngp 

probabi  1 i ty(r-r)=  0.300000 

parameter  len/;th(pl)=  100 

display  o, ior.it ion s(do) 

* Rotation 

* operation  count(doc)=  3 

traverse 

sizc(rsiz)=  5121.' 

instruct  ions (mins) = 30C. C0C000 

me*  nry  ; vinagonenib  nr.i  ■)  =\: 
si  te(nsl  t)=  2 

user  return  parameter  length( rpl )=  0 

user  return  probabi 1 i ty(rpr)s  0.000000 

file  rc. ferences(fr) 
piedb 

roads ( rn)  = Iv.OOGOOC 

v.ri  tcs(wa)=  0,010000 

Figure  3.4  (continued) 
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t i Ies( . i le) 
appdb 

buffer  size(bs)=  5120 

nu'bcr  of  !>uffers(bn)  = 1 

total  size(ts)=  io24 oO 

access (acc)=r 
buffer  i . «.i  idl'd  non  t ( b; . , ) =a 
site(fsit)=  1 

piedb 

buffer  si/e(bs)-  L>12L 

nui'ijer  of  l>uffers(bn)=  1 

total  size(ts)=  51200 

nccess(acc)=r 
buffer  unanor  *int(b 
site(fsit)=  2 

cortbl 

buffer  slzo(bs)=  5120 

number  of  buf fcrs(bn)=  1 

total  size(ts)=  20400 

access(acc)=r 
buffer  r.vitiacer,ient(bn)  =v 
site(fsit)=  2 

display  operation  sct(cios) 

,1otat  ion 


(jaranieter  lnrurthCopl ) = 1 

sitc(osil)=  2 

memory  r.ina^oiinntCoMet  :)=r 
hardware -software  opcion(ho)3hs 
Sasic  Operation  Sot 

para,, to  ter  lon^th(opl )=  1 

site(osit)=  2 

i.icmory  , iinapor  "ent(oi.<  • 0-r 
hardware- sof twa rc  op t i on ( ho ) =hs 
Subroutine  Jur.p 

psraiieter  lon;;th(opl  ) = 1 

site(osit)=  2 

iierory  ; villager 'nnt(o;<'i  )=r 
hnrd/are-sof tware  op t ion(ho)  =! is 
user(uscr) 

user  think  tine(utt)=  5.700000 
user  ivciulr  references (ui  r) 

lex:;p 

p robot.  i 1 i ty(  upr)  = 1 . 000000 

l>arar.v:ter  lr.nr.tl  (upl )=  f C 

regui  rrc.Tonts(  rru) 

flicker  tolerance(f 1 )=  0.050000 

display  us-v,e(uu) 

Power  ,\  ,.l  if  ier 
Transistor 


r.rU  1 1 i pi  ic  i ty(  s:  *j1  ) = 2 

eperat ions(pop) 

:,asic  Deration  Tot 

multipl  icity(por-)=  120.000000 
Subroutine  Ju  p 

i,,ul  t i|  1 ici  ty(ix»  •,)=  10.000000 


Figure  3.4  (continued) 
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trunsfors(tr) 
xfori  r.P 

probnbi 1 i ty(pr)=  1.000000 
parameter  lennth(pl )=  50 

display  ojjerat  ions(do) 
lexapp 

sizo(nsiz)=  0120 

instruct  ions(.'iins)  = 50.  C00U0O 

i lcirory  ; ..naaement(r.Tner  )=\. 
si  te(i.isi  t)=  1 

user  return  parameter  lenr.tl.Crpl  ) = 
user  return  probab? J ity(rpr)=  0.000000 
file  ri feroncosC f r ) 
transfers(tr) 
soman  t i x 

prcljabi  1 i ty(pr)=  0.200000 

parameter  len,"th(pl  )=  50 

syntax 

probability  (;>r)  = 0.200000 

jx.  rave  ter  1 oin-.t! :( ;il  )=  50 

lexer. 

probabi  1 i ty(pr)=  0.400000 
parameter  lenr,tb(pl  )=  10 

d|>UCOMp 

probabi  1 i ty(pr)=  0.100000 

pc<rni.x.'ter  lonr.lMpl )=  10 

xf or  V'P 

probnbi 1 i ty(pr)=  0.10000C 

ixirameter  lenr.c'  Cpl  )=  20 

display  opcrations(do) 
su.iuntix 

si  zc(;  is i z ) - 51200 

instruct  ionsCm  ins)  = 500. 00000C 

memory  r lananemei i t ( rrrror  ) =w 
site(iasit)=  1 

user  return  parameter  lenrtls(  rpl  ) = 
user  return  probab il i ty( rpr)=  0.000000 

file  roforencesC f r) 
aPPf'b 

reads ( ra)=  C.  jOCOOO 

wri  tes(v.a)  = 0.  100000 

piedb 

reads( ra)=  0.400000 

v.-r  i tos(v.a)  = 0.200000 

trunsfers( lr) 


0 


Figure  3.4  (continued) 
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,Res  i star 

nultipl  ici  ty(si  iul)  = 
operations (pop) 

Basic  Operation  Set 
nul  tipi  ici  ty(poi.’)  = 
Subroutine  Jump 

nul  tipi  ici  ty(|x*.i)  = 
Rotation 

r.x_!  1 tipi  ici  ty(pon;)  = 

Capacitor 

nultipl  ici  ty(s.  ul  ) = 
operations(pop) 

Sasic  Operation  Get 
mult  ipl  ici  ty(pa  0 = 
Subroutine  .Jimp 

mult  ipl  ici  Ly(pom)= 
Rotation 

nultipl  ici  iy(|xx'.)  = 
Transforrcr 

nul tipi  ici ty(s nul )= 
operations(pop) 

Dasic  Deration  Get 
nul tipi ici ty( pom)  = 
Subroutine  Jump 

nultipl ici ty(po~)= 

Diode 

nul  t ipl  ici  ty(s  tuI  ) = 
o|  jurat  ions(  pop) 

Dasic  Operation  Get 
nultipl  ici  ty(pon)= 
Subroutine  Jump 

nul  tipi  ici  ty(ixm)  = 
.Rotation 

mil  tipi  ici  Ly(;xx  i)  = 

remote  fast  store  s[x:cif icntions(rf5,s) 
Cycle  Ti.  c 

value(v.il)=  IRCo 
remote  bull;  store  six.cif icat ians( rbss) 
Size 

value(val)=  -2CCC0CG 


epu  spcci f ications(cpus) 
Access  Tim: 

valuc(val)=  IOC'j 

.!pu  specif icat ions (dt.us) 
resolution 

valuc(val)=  hr; 

colors 

valuc(val)=  I 

Jata  1 ink  specif  lent  ionsOMs) 
D i s LdP.cc 

yaluc(val)=  i 


Figure  3.4  (continued) 
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The  optimization  process  has  four  maior  inputs: 
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a hardware  file,  describing  the  host  computer  and  the 
subsystems’  price  and  performance 

- an  application  file,  describinq  the  interactive 
qraphics  application  proqram  for  which  the  satellite  is 
beinq  desiqned 

- the  maximum  allowable  cost  of  the  satellite  system 

- the  number  of  interactive  display  consoles  connected 
to  the  satellite  computer. 

The  optimization  output  qoes  to  a file,  and  is  a description 
of  the  satellite  system  hardware  and  the  software  divisions 
of  labor  which  provides  the  fastest  response  time  and  costs 
no  more  than  the  specified  maximum  number  of  dollars.  Since 
response  time  is  increased  by  selectir.q  faster,  more 
expensive  subsystems,  the  optimum  satellite  system  in  cost 
will  be  close  to  the  maximum  cost.  Since  we  will  deal  with 
a fairly  small  number  of  subsystems,  with  discrete  costs,  it 
would  be  unusual  for  the  satellite’s  cost  to  exactly  equal 
the  maximum  cost. 

The  input  and  output  tiles  and  other  optimization 
parameters  are  specified  to  the  OPT  mode  of  SATHODEL.  The 
optimization  occurs  in  several  steps:  amalqamatinq  the 
hardware  and  application  proqram  descriptions,  and  then 
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searchinq  for  the  optimum  system, 

V 

The  two  files  are  first  read  and  validated.  Subsystems 
not  meetinq  the  selective  specifications  are  discarded.  If 
a flicker  rate  limitation  is  specified  in  the  application 
file,  ther.  DPU’s  which  cannot  meet  the  requirement  are 
discarded.  Then  the  DPU’s  are  paired  with  compatible  CPU’s 
chosen  from  the  hardware  file.  At  this  point  the  entire 
input  data  is  checked  for  completeness  and  consistency. 
Finally,  the  actual  optimization  is  performed. 
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U . 1 General  Use 

Within  this  qeneral  optimization  framework,  the 
optimizer  can  be  used  in  several  ways. 

pivision  of  labor  Only 

A hardware  file,  containing  only  one  cf  each  subsystem, 
is  created.  The  subsystems  are  those  of  the  satellite, 
graphics  system  for  which  an  optimum  division  of  labor  i 
desired.  The  application  fill  describes  the  appropriit- 
application.  The  SITE  attribute  for  the  modules  and  filer, 
which  can  be  resident  at  either  the  host  or  satellite  is  set 
to  0.  For  all  others,  the  SITE  attribute  is  set  to 
represent  the  permanent  assignment.  The  maximum  cost  is  set 
to  any  value  greater  than  or  equal  to  the  sum  of  the 
individual  subsystems*  costs. 

Optimum  Satellite  System  Only 

A full  hardware  file  is  used,  with  several  different 
entries  for  each  type  of  sub. /stem.  In  the  applications 
file,  all  SI TP  attributes  are  set  to  one  or  two,  giving  a 
fixed  division  of  labor.  Memory  management  attributes  would 
also  be  assigned  a single  value,  so  they  don't  enter  into 
the  optimization  process  either.  Since  any  division  of 
labor  implies  minimum  memory  requirements  at  the  satellite, 
some  satellite  main  and  bulk  memory  subsystems  may  not  be 
considered  in  the  optimization. 
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The  desired  maximum  cost  is  qiven,  as  usual. 

jt 

V 

Cost  vs.  Response  Tine  Curves 

Curves  for  cost  versus  minimum  response  time,  such  as 
those  in  The  Second  Annual  Report.  are  very  useful  in 
finding  when  the  returns  cn  increased  investment  beqin  to 
decrease,  or  to  find  the  cost  of  attaininq  a specified 
response  time.  Data  points  on  the  curve  are  found  by  makinq 
multiple  optimization  runs  chanqinq  only  the  maximum  cost 
between  runs.  One  should  start  with  a maximum  cost  equal  to 
the  sum  of  the  costs  of  each  of  the  lowest- pr iced 

* 

subsystems,  and  end  with  the  sum  of  the  costs  of  each  of  the 
i hiqhest- priced  subsystems.  From  5 to  10  intermediate  costs 

I* 

are  generally  sufficient  to  qivs  a reasonably  useful  curve. 
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4.2  Optimization  Speed 

With  the  TUCC  IBM  370/165,  c.  »o  10  minutes  of  CPU  time- 
were  needed  to  do  a hardware  optimization  with  about  4 or  5 
different  choices  of  each  of  the  four  subsystems  and  no  more 
than  2C  unassiqned  modules  or  tiles  in  the  applicatioi 
description.  We  cannot  directly  relate  this  time  to  an 
equivalent.  number  of  01*645  minutes.  However,  since  HULT1CS 
is  a multi-user,  interactive  syst  as  much  as  20  or  30 
actual  minutes  may  be  needed  to  .tain  1 minute  of  CPU  tise. 
Assuminq  a 1 to  1 spaed  ratio,  t he  10  minutes  of  CPU  time 
could  require  as  much  as  fiv^  hours  of  elapsed  time.  We 
thus  suqqest  overniqht  "batch"  runs  for  optimization  of  this 
scope.  Some  smaller  optimization  will  doubtless  be  feasible 
to  do  interactively. 

If  the  number  of  consoles  at  the  satellite  is  more  than 
one,  optimization  times  are  qreater  than  in  the  sinqle-user 
case,  since  a natworlc  of  queues  is  solved  usinq  an  iterative 
alqorithm,  RQA.  Thus  multi-console  systems  should  be 
analyzed  sparinqly,  and  with  as  few  subsystem  choices  and 
unbound  modules  and  files  as  possible.  The  maximum 


allowable 


number  of  consoles  is  about  five 


